Please add the PR number here. (A couple others are missing them as well but let's try not to make that a pattern please <3.)

Should we be specifically promoting use of 0.0.0.0? Seems like this message should encourage the user to think about their choice. Like "set the Server Listen Address (use 0.0.0.0 to accept all incoming connections)". I feel like the way it's worded right now has the same security concern as before because a lot of users are just going to read this and then set 0.0.0.0 while wondering why we don't just do that automatically.

I agree, but realistically there are only two choices here: bind to 127.0.0.1 or bind to 0.0.0.0. The key differentiator between the two being that 0.0.0.0 allows connections from remote devices. Sure, it's possible to set it to the IP address of a specific network adapter, but that's for people who know what they're doing (and they're not the audience of this warning).

The only reason to use 127.0.0.1 is security, and I'm wary of stating that in the warning because it implies that 0.0.0.0 is less secure in some way (when in fact if you want to accept remote connections you'll be opening a port to the outside anyway). To me it really boils down to whether the user needs to accept connections from remote devices or not. (The answer to that question being yes most of the time is why I originally made 0.0.0.0 the default.)

I'm open to suggestions on how to rephrase the warning, however.

I suppose, but that makes me wonder if we should even have an IP entry by default or if this should be a checkbox for "Accept remote connections" and put the text box under a collapsed "advanced settings" section. Then the warning could just say "Warning: Running in local mode. Connections from remote devices will not be accepted. To change this, check 'accept remote connections' in NetworkManager settings".

If we know that most users will only be choosing between two possible values for that field, why not just make it a boolean field and hide the advanced configuration so only advanced users need to think about it at all?

• Accept Remote Connections

I agree, and in hindsight a checkbox really would have been the better option here. I'm not sure about adding this at this point, though. I'm afraid this will just add more complexity to a component (UnityTransport) which already doesn't exactly shine by how straightforward it is to use.

Adding this without breaking the API would probably require adding a custom editor component for the settings (we can't just add a separate advanced settings structure to ConnectionData because ServerListenAddress is already a member and I've seen users set it manually from code). We'll also need to add logic to harmonize the checkbox and the text field. For example, what happens if I check the box but set the bind IP to 127.0.0.1?

All of that for an option which, as you astutely point out, users are just going to blindly enable and wonder why it's not the default behavior. Ultimately the IP the server binds on is a relatively minor consideration in the grand scheme of creating a multiplayer game. I think the amount of effort we put into handling it should reflect that.

Yeah, a custom editor component was what I had in mind actually. No changes to the actual runtime code, just a custom editor component that fills that box with 127.0.0.1 or 0.0.0.0 as necessary based on the state of the checkbox, probably disabling the checkbox if the user's manually entered anything there.

Might be too much for a quick bugfix to go into an already-cut release branch, but since we seem to be in agreement that that'd be a better solution, maybe we could make a task for later to adjust that for 1.3.1?

Yes, that sounds good! I think it would make a great improvement for the next release.